feat: Add labels for root parent object #14578
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Scott Fleener <[email protected]>
sfleen
force-pushed
the
sfleen/trace-parent
branch
from
e57df5a to
1d643ee
Compare
sfleen
changed the title
sfleen
commented
Oct 6, 2025
alpeb
reviewed
Oct 6, 2025
Member
alpeb
left a comment
alpeb
left a comment
There was a problem hiding this comment.
Looks good to me 👍
I guess the path forward is to remove the old logic along with its labels. If so, can you flag that in the the the labels.go's label entry godoc? Should also be mentioned in the release notes.
The GroupVersionResource requires the resource to be both lowercase and plural. Signed-off-by: Scott Fleener <[email protected]>
Signed-off-by: Scott Fleener <[email protected]>
Member
|
I don't think 'kind' is sufficient. I think we must also include 'group' |
Signed-off-by: Scott Fleener <[email protected]>
alpeb
approved these changes
Oct 8, 2025
Signed-off-by: Scott Fleener <[email protected]>
Co-authored-by: Alejandro Pedraza <[email protected]>
Contributor
Author
|
I added in the group as an annotation, as well as some more webhook tests to make sure we have more coverage here. |
sfleen
added a commit
that referenced
this pull request
Oct 8, 2025
This replaces the old pod owner mechanism with the new one introduced by #14578. This retains the previous annotations for now, we can remove them later in a follow-up. Signed-off-by: Scott Fleener <[email protected]>
sfleen
added a commit
that referenced
this pull request
Oct 8, 2025
This replaces the old pod owner mechanism with the new one introduced by #14578. This retains the previous annotations for now, we can remove them later in a follow-up. Signed-off-by: Scott Fleener <[email protected]>
sfleen
added a commit
that referenced
this pull request
Oct 8, 2025
This replaces the old pod owner mechanism with the new one introduced by #14578. This retains the previous annotations for now, we can remove them later in a follow-up. Signed-off-by: Scott Fleener <[email protected]>
sfleen
added a commit
that referenced
this pull request
Oct 8, 2025
This replaces the old pod owner mechanism with the new one introduced by #14578. This retains the previous annotations for now, we can remove them later in a follow-up. Signed-off-by: Scott Fleener <[email protected]>
sfleen
added a commit
that referenced
this pull request
Oct 9, 2025
* chore(inject): Replace root owner mechanism This replaces the old pod owner mechanism with the new one introduced by #14578. This retains the previous annotations for now, we can remove them later in a follow-up. Signed-off-by: Scott Fleener <[email protected]> * chore(inject): Remove version from root owner labels Signed-off-by: Scott Fleener <[email protected]> * chore(tests): Update goldens Signed-off-by: Scott Fleener <[email protected]> --------- Signed-off-by: Scott Fleener <[email protected]>
sfleen
added a commit
that referenced
this pull request
Oct 13, 2025
This reverts commit f2989ea Signed-off-by: Scott Fleener <[email protected]>
sfleen
added a commit
that referenced
this pull request
Oct 13, 2025
This reverts commit f2989ea Signed-off-by: Scott Fleener <[email protected]>
sfleen
added a commit
that referenced
this pull request
Oct 13, 2025
* Revert "chore(inject): Replace root owner mechanism (#14593)" This reverts commit 9f5201e. * Revert "feat: Add labels for root parent object (#14578)" This reverts commit f2989ea Signed-off-by: Scott Fleener <[email protected]> --------- Signed-off-by: Scott Fleener <[email protected]>
sfleen
added a commit
that referenced
this pull request
Nov 4, 2025
This is a roll-forward of #14578, albiet with a slightly different implementation. The original PR would fall back to direct metadata API calls when getting resources from the informer cache. This instead resyncs the informer when a resource cannot be found and tries again, skipping the direct metadata API entirely. Original PR description: Currently, we add a label that identifies the parent resource that a proxy is attached to, usually a deployment, statefulset, daemonset, etc. These are populated via `linkerd.io/proxy-<resource>`` annotations, with a different label for each parent resource. There are a few deficiencies with the current implementation. Currently, the implementation is specialized to only built-in k8s resources, so things like argocd rollouts will not appear. Additionally it does not recurse beyond two levels, so any more levels of parenting will not be captured. This adds a set of new labels, `linkerd.io/proxy-root-parent` and `linkerd.io/proxy-root-parent-kind`, and `linkerd.io/proxy-root-parent-group`, that identify the name and kind of the root parent of a proxy workload. It also correctly recurses to the true root resource, at least as far as cluster role permissions for the proxy injector permit. Note that the proxy already consumes all of the pod labels via the downward API, so there's no changes required to the proxy injector templates. Signed-off-by: Scott Fleener <[email protected]>
sfleen
added a commit
that referenced
this pull request
Nov 4, 2025
This is a roll-forward of #14578, albiet with a slightly different implementation. The original PR would fall back to direct metadata API calls when getting resources from the informer cache. This instead resyncs the informer when a resource cannot be found and tries again, skipping the direct metadata API entirely. Original PR description: Currently, we add a label that identifies the parent resource that a proxy is attached to, usually a deployment, statefulset, daemonset, etc. These are populated via `linkerd.io/proxy-<resource>`` annotations, with a different label for each parent resource. There are a few deficiencies with the current implementation. Currently, the implementation is specialized to only built-in k8s resources, so things like argocd rollouts will not appear. Additionally it does not recurse beyond two levels, so any more levels of parenting will not be captured. This adds a set of new labels, `linkerd.io/proxy-root-parent` and `linkerd.io/proxy-root-parent-kind`, and `linkerd.io/proxy-root-parent-group`, that identify the name and kind of the root parent of a proxy workload. It also correctly recurses to the true root resource, at least as far as cluster role permissions for the proxy injector permit. Note that the proxy already consumes all of the pod labels via the downward API, so there's no changes required to the proxy injector templates. Signed-off-by: Scott Fleener <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently, we add a label that identifies the parent resource that a proxy is attached to, usually a deployment, statefulset, daemonset, etc. These are populated via
linkerd.io/proxy-<resource>annotations, with a different label for each parent resource.There are a few deficiencies with the current implementation. Currently, the implementation is specialized to only built-in k8s resources, so things like argocd rollouts will not appear. Additionally it does not recurse beyond two levels, so any more levels of parenting will not be captured.
This adds a pair of new labels,
linkerd.io/proxy-root-parentandlinkerd.io/proxy-root-parent-kind, that identify the name and kind of the root parent of a proxy workload. It also correctly recurses to the true root resource, at least as far as cluster role permissions for the proxy injector permit.Note that the proxy already consumes all of the pod labels via the downward API, so there's no changes required to the proxy injector templates.